home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0063.001 < prev    next >
Text File  |  1992-05-10  |  10KB  |  280 lines
  1. Document: FSC-0063
  2. Version:  001
  3. Date:     10-May-1992
  4.  
  5.  
  6.  
  7.  
  8.                       A Proposal for FidoNet style messages
  9.                                    Jem Miller
  10.                                1:147/33.0 @FidoNet
  11.  
  12.  
  13.  
  14.  
  15. Status of this document:
  16.  
  17.         This FSC suggests a proposed protocol for the FidoNet(r) community,
  18.         and requests discussion and suggestions for improvements.
  19.         Distribution of this document is unlimited.
  20.  
  21.         Fido and FidoNet are registered marks of Tom Jennings and Fido
  22.         Software.
  23.  
  24.  
  25.  
  26.  
  27.         I. Introduction
  28.  
  29.              The current message strucures that are  transmitted  between
  30.         systems is fast becoming outdated.  Dupe checking, path checking,
  31.         and zone aware routing are all areas of weekness in  the  current
  32.         format.  This  proposal  both  simplifies  the current processing
  33.         needed of mail tossers,  and eliminates the worst  problem  areas
  34.         and limitations of the current methods.
  35.  
  36.              Currently,  Seen-By  lines  and  Path lines are appended and
  37.         maintained in all EchoMail type message sent into FidoNet technol-
  38.         ogy networks.  The original intention of Seen-By's  was  to  help
  39.         eliminate  duplicate messages,  and give a sort of "tracking his-
  40.         tory" of each piece of EchoMail.  Path lines tell us what systems
  41.         have  actually  processed the mail and sent it on to another sys-
  42.         tem, and offer some audit checking in case of problems.
  43.  
  44.              Unfortunately,  these systems can not reliably detect and/or
  45.         correct duplicate messges,  or point to the offending system with
  46.         any surity. In recent times, a MSGID kludge has been used, requir-
  47.         ing the maintaining of databases (one per echo usually)  to  test
  48.         each message for duplication.  While this procedure cures much of
  49.         the duplication problems,  it does nothing for the audit trail of
  50.         each  message.  Further,  it needlessly slows the tossing/packing
  51.         process, and promotes disk fragmentation problems further.
  52.  
  53.              Yet another consideration as we enter wider  acceptance  and
  54.         useage  of  our  electronic  media  is overhead.  Overhead can be
  55.         viewed in many ways,  two of the most important are Cost per mes-
  56.         sage  to transmit,  and disk space used for needless information.
  57.         The proposed changes outlined below address all  of  these  items
  58.         and more, giving a means of expanding into the future.
  59.  
  60.         II. Proposed Changes
  61.  
  62.              Seen-By lines will be greatly changed as compared to the cur-
  63.         rent  structure,  Path  lines  will be eliminated,  and the MSGID
  64.         kludge will also be eliminated.  Tear lines and origin lines will
  65.         remain unchanged.  INTL kludges, FMPT kludges, and others will be
  66.         eliminated.
  67.  
  68.              This audit system is not new in concept.  In fact it is cur-
  69.         rently used in a similar manner in the popular TICK and FLEA file
  70.         echo processors.  Each system that processes a piece of mail adds
  71.         its node number into an audit list.  The audit list is similar to
  72.         current Seen-By's only in that node numbers are listed at the end
  73.         of each message.
  74.  
  75.              Node  numbers added to the audit list are FULL node numbers,
  76.         ie.
  77.  
  78.         Zone:Net/Node.Point
  79.  
  80.                                         1
  81.  
  82.  
  83.              A system ALWAYS adds itself to the  Audit  list,  but  NEVER
  84.         adds  any  other  system address to the list.  The mail processor
  85.         must be capable of automatically zone matching its own  node  ad-
  86.         dress to that of the system it is currently sending a message to.
  87.         For  example:  If I am sending an echo to zone 1 AND zone 42,  my
  88.         mail processor would add the following Audit entries:
  89.  
  90.         For each zone 1 message:
  91.         1:147/33.0
  92.         For each zone 42 message:
  93.         42:1036/33.0
  94.  
  95.              My system then sends the message to the  correct  receivers.
  96.         If  the receiver is at the end of a line (not sending the area to
  97.         any other systems),  it simply checks the audit  list  to  ensure
  98.         that the senders address is listed only once, and tosses that mes-
  99.         sage to the correct area.
  100.  
  101.              ONLY  SYSTEMS  THAT  RE-SEND A MESSAGE add themselves to the
  102.         Audit list.  A system NEVER adds itself to the Audit list if  its
  103.         sending system is listed more than once.  In this case,  the mes-
  104.         sage is a duplicate, and is killed.
  105.  
  106.              The Audit list is NEVER sorted,  or disturbed in any way ex-
  107.         cept to add a new node to the end of the list.
  108.  
  109.              There are no databases to maintain,  no path lines to check,
  110.         and best of all,  only SENDING systems are  listed.  In  national
  111.         echos,  it is not uncommon to see 5 to 8 lines of Seen-By's and 2
  112.         or 3 path lines in EACH message.  Even though including the  full
  113.         zone  address  (including points) adds to the length of node num-
  114.         bers,  far fewer node numbers  are  listed.  In  the  case  of  a
  115.         problem,   the   offending  system  can  be  quickly  and  easily
  116.         idetified, and the problem corrected.
  117.  
  118.              Security is also enhanced by allowing the mail processor  to
  119.         check  the  sending  system against its send-to list in the areas
  120.         file to determine that it was received from the correct node  ad-
  121.         dress (the senders address can be cross checked by the Audit list
  122.         as well as the packet header).
  123.  
  124.  
  125.  
  126.         III. Implementation
  127.  
  128.  
  129.  
  130.         A. Packet Header
  131.  
  132.              The  current  packet  header  needs  no  changes (except the
  133.         packet type identifier). This allows full backward compatibility.
  134.  
  135.  
  136.  
  137.         B. Packed Messages
  138.  
  139.              No change to packed message structures or procedures.
  140.  
  141.  
  142.  
  143.         C. MSGID Line
  144.              Eliminated.
  145.  
  146.  
  147.                                         2
  148.  
  149.  
  150.         D. Message Body
  151.  
  152.              Unchanged.
  153.  
  154.  
  155.  
  156.         E. Tear Lines
  157.  
  158.              Unchanged.
  159.  
  160.  
  161.  
  162.         F. Origin Lines
  163.  
  164.              Unchanged.
  165.  
  166.  
  167.  
  168.  
  169.         G. Seen-By's
  170.  
  171.              Replaced by Audit list.  The Audit line begins with a unique
  172.         tag:
  173.  
  174.         AUDIT:
  175.  
  176.         followed by a space (ASCII #32). Each node number is seperated by
  177.         a  space.  Each Audit line is terminated by a carriage return and
  178.         optionally a linefeed (ASCII #13 and #10).  The  length  of  each
  179.         Audit  line  follows  current  Seen-By  line  specifications  (79
  180.         characters).
  181.  
  182.              Node numbers in the Audit list are full  Zone:Net/Node.Point
  183.         numbering. The maximum feild length per entry is 23 characters of
  184.         text up to and including:
  185.  
  186.         65535:65535/65535.65535
  187.  
  188.  
  189.  
  190.         H. Path Lines
  191.  
  192.              Eliminated.
  193.  
  194.  
  195.  
  196.  
  197.         IV. Operations
  198.  
  199.  
  200.  
  201.         A. Sender
  202.  
  203.              The originating system begins the Audit sequence by creating
  204.         the  initial  Audit  line  and  adding  his node number after the
  205.         AUDIT: tag.
  206.  
  207.         AUDIT: 1:147/33.0
  208.  
  209.              Then packs the message to the receiving system  as  it  nor-
  210.         mally would.
  211.  
  212.  
  213.  
  214.                                         3
  215.  
  216.              A  system  that  is  re-sending the message to other systems
  217.         first completes the Receiver requirements in step B  below.  Then
  218.         the  system  adds  its own node number (zone matched) to the LAST
  219.         Audit line of the message (or creates a new line if needed).  The
  220.         sender then packs the message as it normally would.  This process
  221.         is repeated for each message,  and each system  that  recieves  a
  222.         copy  of the message.  Zone gates may or may not be listed in the
  223.         Audit list to correctly identify any problems (open to ruling).
  224.  
  225.  
  226.  
  227.         B. Receiver
  228.  
  229.              Upon processing a packet,  the receiver scans for the  Audit
  230.         lines as it currently does for a Seen-By line for each message it
  231.         processes.  Each  entry  in the Audit list is checked against the
  232.         LAST entry, as well as its own address, for duplication. Addition-
  233.         ally,  the LAST address is checked against the receivers list  of
  234.         valid  systems  for  that message area to insure that security is
  235.         not breeched.  Optionally,  the receiver may check the address of
  236.         the  packet header against that of the senders Audit entry to en-
  237.         sure correct addressing.
  238.  
  239.              After all tests are made,  the message is tossed to the cor-
  240.         rect message area.  If the receiver is to send the message to any
  241.         other systems, it then becomes the sender and procedes as in step
  242.         A above.
  243.  
  244.  
  245.  
  246.         V. Qualifications
  247.  
  248.              I am a programmer by trade,  and hold a degree in Electronic
  249.         Engineering.  I attended Oklahoma State University, and MIT. I am
  250.         the author of the SuperComm bulletin board system which includes:
  251.  
  252.         SCBBS     The BBS program
  253.         SCMAIL    The Mail processor
  254.         SCED      The offline Message editor
  255.         SCSET     Set-up utility
  256.         SCNET     Network interface (Front-end mailer).
  257.  
  258.              The SuperComm system holds a current FidoNet  product  code,
  259.         and  is fully compliant in its mail handling.  A working model of
  260.         ScMail including these changes is available  for  review.  Source
  261.         code ideas are also available for the proposed changes, either in
  262.         C or Turbo Pascal.
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.                                         4
  279.  
  280.